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ABSTRUCT 


Current corrective maintenance practices .ii' U.S. Navy 
ships follow troubleshooting guides found in the paper copies 
of technical manuals. These manuals are often difficult to 
find, maintain, and store, and guides are not easily followed. 
An expert system for troubleshooting could improve current 
practices by providing a centralized program that is easily 
maintained and followed. By coupling to a database of 
procedures, the precise steps to correct the problem could 
also be called. An expert dateODase system allows an expanded 
knowledge base that is easily modified while maintaining the 
integrity of the expert system program. 

A prototype system for troubleshooting the NAXI 100-2 Low 
Pressure Air Compressor was developed to illustrate the 
advantages of expert database technology in this application. 
VP-EXPERT and DBASE IV were used, and the prototype as 
demonstrated to SIMA, San Diego, was received favorably. 
Conclusions drawn supported the feasibility of such systems to 
assist in the performance of shipboard maintenance. 
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I. INTI^DqCTION 

A. BACKGROUiq^ 

Within the warships of today' s - modern US Navy the 
effective corrective maintenance of main propulsion and 
auxiliary machinery requires a vast array of technical 
expertise and written reference material. Other than the 
supply functions on SNAP II (an installed minicomputer for 
administrative support) equipped ships, troubleshooting and 
repairs are completely manual, and often imprecise or 
misdirected. Some specific problems are as follows: 


1. The expertise of technicians varies widely from ship 
to ship and from sailor to sailor. The moire senior petty 
officers and chief petty officers show a wide range of 
experiences and knowledge. Even when specifically trained 
and coded for a certain class of ship or machinery, levels 
of expertise are far from standard. 

2. Current troubleshooting practices rely heavily on a 
plethora of technical manuals, PMS (planned maintenance 
system) cards, owner's manuals, or pass down notes and 
checklists. All this paper u^^s not hold up well on the 
deckplates, and important pages are often stained, torn, 
or removed in the repair process. Nvimerous paper copies 
also use an incredible amount of precious space, and this 
issue has prompted new research such as the paperless ship 
initiative to reduce the amount of paper on U.S. naval 
ships. Even with many duplicate copies present aboard 
ship, a needed technical manual often cannot be found in 
its assigned location. 

3. Technical libraries are notoriously difficult to keep 
up to date, properly sorted, centrally located or 
distributed as required. Technical librarians are often 
junior sailors, or even worse, sailors who can not do 
anything else. They are usually not formally trained, and 
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often are helci accpunteibie for documentation to equipment 
that they have little interest in themselves 

4. There is often an inadequate record of maihtehance. 
actions performed' on specific equipment; |ih automated 
system could conceivably keep an effective audit trail of 
the actions taken and how often. Manual notebooks antf 
equipment material histories currently in use are often 
out of datOf iiiegibie, or misplaced. 

5. Many sailors are intimidated by large unwieldy 
technical manuals that can be difficult to navigate 
through. The organization and logical flow of the 
troubleshooting sections of many technical manuals are not 
always intuitively obvious, and can further discourage the 
average sailor. 


A computerized expert database, system develpped from a 
commercially available expert system shell and database 
management system could greatly mitigate many aspects of the 
aforementioned problems. By coupling an expert system to a 
database, the knowledge base could be greatly expanded while 
still maintaining the flexibility of a database system. This 
would allow the many changes due to frequent technical updates 
to be incorporated separately in the database while 
maintaining the integrity of the expert system program. This 
thesis will develop a prototype of such a system for a 
specific equipment to prove the viability of integrating 
expert system and database management technology in performing 
shipboard maintenance. 


B. OBJECTIVES 

The objectives of this thesis are to demonstrate the value 
o-^ expert system technology in the performance of shipboard 
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ihaintehance, and to corabihe an expert system ,jfith a databaise 
management system to produce a working expert database, system. 

C. iaSSJACH QUESTIONS 

This study seeks to answer the following primary and 
Secondary research questions: 

Can an expert database system assist maintenance personnel 
in the performance of shipboard corrective maintenance? 
it will also address the four following questions: 

1. Can a commercially available expert system shell 
(VP-EXPERT) be used to develop a working prototype? 

2:. Can equipment technical documentation be stored in a 
commercially available database management system (DBASE 
IV) and effectively called upon by an expert system? 

3. What are the benefits of using an expert system for 
troubleshooting shipboard machinery? 

4. What type arid degree of coupling will be required 
between the expert system and the database management 
system? 

D. SCOPE 

Shore Intermediate Maintenance Activity (SIMA ), San Diego, 
provided the technical documentation for a NAXI 100-2 Low 
Pressure Air Compressor to form the prototype's knowledge 
base. The system has been designed to guide the user through 
the basic troubleshooting process by first identifying the 
symptoms, possible causes, and finally, what solutions are 
available. The system interfaces with a database management 
system to call up selected procedures to be used for problem 
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solutions,. Ah initial prototype expert system was 4®vei6ped 
and taken to SIMA for testing by the appropriate res4'd®ht 
experts. The exj^ert system was then coupled to a dateODase to 
form the final, prototype to detemihe if this* form of 
shipboard maintenance is, a feasible application of an expert 
database system. 

E. METHODOLOGY 

A prototyping approach was followed in the design and 
development of this syscem. Knowledge was acquired for the 
system principally from the technical manual's troubleshooting 
guide and phone interviews with equipment experts from SIMA, 
San Diego, This knowledge was used to develop "if-then" rules 
for the expert system shell. The expert system interacts with 
the user with a set of questions, and the replies trigger the 
rules to provide expertise. Separate procedures to be used to 
complete the solution are kept in a separate database and 
called on demand. 


F. ORGANIZATION 

The following is a summary of the chapters: 


I. Introduction - The background, objectives, research 
questions, scope, methodology, and organization of the 
research is presented. 

II. Current Environment - The current maintenance 
practices in use in the fleet, and the current expert 
system and database technology available is reviewed in 
this chapter. 
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III. Analysis and Design of the Expert System Component - 
This chapter includes the decision domain, design and 
implementation of the expert system component. 

IV. Analysis and Design of the Database System Component 
This chapter includes the definition, requirements, 
design and implementation of the database system 
component. 

V. Conclusions and Lessons Learned - The first and second 
prototype reviews, the lessons learned using the VP-EXPERT 
shell and DBASE IV database system, and the j-esearch 
conclusions are presented. 

Appendices - These sections include the expert system 
decision tree, sample consultation, the database object 
and domain definitions, relationships, update and control 
mechanisms, dataflow diagrams, and menus. 
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II. CURRENT ENVIRONMENT 


A. CURRENT TROUBLESHOOT::. 6 METHODS 

The current method for troubleshooting main propulsion and 
auxiliary machinery in U.S. Naval ships is an entirely manual 
process with the exception of the preparation of requisitions 
to the supply department for parts. A problem will usually be 
initially detected by a watchstander who is qualified to 
operate the equipment, but may not be qualified to perform any 
scheduled or corrective maintenance. His normal duties include 
the monitoring of equipment operating parameters and basic 
house cleaning within his assigned space. He is usually 
qualified to start, stop and monitor his assigned equipment 
only within the strict guidance provided by the Engineering 
Operating and Sequencing System (EOSS). EOSS is further 
divided into Engineering Operating Procedures (EOP) which are 
used for starting, stopping, and monitoring of normal 
operation, and Engineering Operating Casualty Control (EOCC) 
which is used to provide emergency response to equipment 
casualties. 

The Naval Sea Systems Command (NAVSEA) provides all 
guidance for the normal operation, casualty control, 
preventive and corrective maintenance of shipboard engineering 
machinery. Technical manuals are provided to each ship for all 
assigned equipment. The paper and microfiche copies are kept 
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in a space designated as the ship's technical library, and a 
sailor is given the job as technical librarian. On large ships 
this may be a primary duty, but on most ships it is a 
collateral duty. 

Technical manuals typically contain general descriptions 
of component systems, safety precautions, operating 
procedures, scheduled preventive maintenance, corrective 
maintenance (troubleshooting), system diagrams, parts list, 
and installation procedures. The technical manual forms the 
basis for EOSS and the Preventive Maintenance System (PMS), 
which are much more specific in their detail. Because they are 
more specific and detailed, EOSS and PMS take precedence over 
the technical manual, but corrective maintenance is usually 
performed using the technical manual alone. In some cases a 
PMS procedure may be used to correct a specific problem (i.e. 
replacing a clogged filter). Changes to procedures which 
require immediate attention may be sent via a radio message or 
class advisory, otherwise routine technical updates and 
changes are sent via normal naval correspondence. 

When a watchstander detects a problem and takes immediate 
action in accordance with EOCC, the equipment is secured and 
a sailor qualified to perform the required troubleshooting is 
called to the space. If the problem's cause is not immediately 
obvious, the technical manual is consulted. Most technical 
manuals contain a troubleshooting guide which can be followed 
to narrow the problem down to its specific cause. This cause 
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is matched with a specific solution to the problem, usually a 
reference to the page and paragraph of a corrective 
maintenance procedure. The corrective maintenance procedure 
outlines the specific steps to be followed, the tools and 
parts required, and any safety precautions and considerations. 

Problems arise as soon as the cause of equipment casualty 
is not readily apparent and the technical manual must be 
consul 1.3d. First a copy of the technical manual must be found. 
If a copy is kept in the engineering space, the chances are 
that it is in poor condition. Space copies are typically 
stained with various greases and oils and plagued by many torn 
and missing pages, and retrieved loose pages are frequently 
shoved back in the manual at random locations. These copies 
are also usually out of date and missing the latest revisions 
and changes. If a copy of the technical manual must be checked 
out of the technical library, it may be in better condition, 
but first it must be found. The manuals are kept in shelves in 
order of their assigned NAVSEA TECHNICAL MANUAL number, so 
first the index must be found, the number looked up, and the 
manual found (provided the last user replaced it properly). 
Since it is usually a collateral duty, the technical librarian 
must fit the proper care of the library in with his own 
primary duties and watchstanding. His duties as the technical 
librarian include making sure manuals are properly checked out 
and returned, ensuring they are kept in the proper order on 
the shelf, and entering the appropriate revisions and changes 


8 



as they arrive. Successful ships know the importance of this 
job, but on many ships there may be a tendency to relegate 
this task to a more junior sailor or one that is less skillful 
in his primary maintenance duties. Consequently, the quality 
of the technical library often suffers.due to inattention or 
neglect. Even if the technical librarian is exceptionally 
competent and diligent, he cannot be present 24 hours a day, 
and must rely on proper procedures being followed in his 
absence. In the rush of a critical repair, proper procedures 
in the technical library are usually given an expectedly low 
priority. 

Once found, the technical manual must be searched for the 
troubleshooting guide. Troubleshooting guides do not follow a 
standard format and may vary greatly in logic and clarity 
between different technical manuals. Some are in paragraph 
form, while others are tabular or follow a flowchart format. 
Many sailors are inunediately inLimidated by the heft and 
complexity of many technical manuals, especially those for the 
larger auxiliary and main propulsion pieces of equipment. 
Reading competency may also vary greatly between sailors, 
which can increase anxiety when faced with multiple volumes of 
technical jargon. The result is that many sailors will perform 
troubleshooting in a haphazard "hit or miss" fashion with only 
a cursory glance at the technical manual. They often rely 
heavily on their own experience and expertise which can vary 
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greatly between individuals, and this often results in an 
inconsistent or ineffective troubleshooting effort. 

An expert system for engineering maintenance could 
alleviate many of the problems that exist in the current 
environment. The central location of a computer would solve 
many of the problems caused by duplicate copies in poor 
condition. There would be no lost time searching the spaces or 
the technical library shelves for the proper technical manual. 
The troubleshooting guide could be logically and clearly 
presented by a series of questions which would guide the user 
to the specific problem and solution. This would avoid the 
intimidation and endless page turning morass of the large 
manuals by focusing the user's attention strictly to the 
question at hand. Since the expert system is providing the 
bulk of the expertise, the system could accommodate a wide 
range of experience and technical competence. An accompanying 
database called by the expert system could logically organize 
the corrective procedures called for display and printing. 

Corrective maintenance, or troubleshooting, as a problem 
domain lends itself exceptionally well to expert system 
development. According to Leibowitz [Ref. 1], a task candidate 
for an expert system must have the following characteristics: 

1. The Task Should Be Well-bounded. 

The task should encompass a relatively specific amount 
of knowledge, consisting of facts within a narrow scope. 
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Machinery troubleshooting is a perfect example of a well- 
bounded and specific task. 

2. The Task Involves Symbolic Versus Numerical 

Processing. 

This refers to the execution of symbols or strings of 
characters. Significant numerical calculations could be better 
performed with conventional programming languages. 
Troubleshooting requires little or no numerical calculations. 

3. The Task Can Be Solved Relatively Quickly. 

If a task requires more than a few weeks to solve than 
an expert system would not be appropriate. Most equipment can 
be quickly analyzed, and the troubleshooting process itself is 
not time consuming when considered separately from tht 
physical process of component disassembly. 

4. The Task Is Performed Frequently. 

The usefulness of an expert system is maximized when 
the expert system is used to solve a task repeatedly. 
Shipboard equipment is run constantly under harsh 
environmental conditions, and breakdowns are frequent. An 
expert system to perform these tasks would get plenty of use 
to justify its development. 

5. There Is A Significant Difference Between the Best and 

Worst Performers 

A task is more suitable for an expert system when 
there is a large discrepancy between the best and worst 
performers of the task. As previously discussed, th.rs is 





certainly the case for most sailors performing troubleshooting 
in the fleet. 

6. Test Data Is Availzd^le. 

This is not a firm requirement, but can be helpful. 
There are plenty of successful troubleshooting cases to serve 
as comparisons for determination of expert system performance. 

7. There Should Be Consensus on How the Task Can Be 

Solved. 

The experts must agree on how to solve the task. 
Again, troubleshooting procedures are clear and well-bounded, 
and there is little room for variation from prescribed 
solutions. 

8. Experts Exist and Can Participate. 

There are plenty of sailors available to tap for 
expertise, and to evaluate a system. SIMA San Diego is a 
particularly good source of qualified technicians with current 
and recent shipboard experience in troubleshooting. 

B. EXPERT SYSTEMS 

An expert system is a knowledge-based computer system that 
attempts to replicate what human experts normally do. Human 
experts may make decisions, recommendations, or actually 
perform tasks. They may also train others to do these same 
tasks or make the same dvcisions. Expert systems are designed 
to perform these functions also. [Ref. 2] 
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For this study the term expert refers to a troubleshooting 
repair person who is particularly adept at his job. The expert 
system enables a user with a problem (i.e., how to find the 
cause of machinery failure and a way to repair it) to use a 
computer system as they would an expert advisor to guide them 
through diagnosing what might be causing the problem and how 
to solve it. This is called a consultation. 

Like a human expert, the system can extract additional 
information or data from the user with questions related to 
the problem. During a consultation the system can also answer 
questions about why certain information is needed and the 
reasoning steps gone through to reach a conclusion, and it can 
make recommendations for solving the problem at the end of the 
consultation. [Ref. 3] 

The distinguishing characteristics of expert systems are 
that they: 

1. Contain symbolic programming and reasoning 
capabilities. 

2. Contain a knowledge base about a specific decision 
domain distinct from the inferencing mechanism. 

3. Contain an inference engine distinct from the 
knowledge base. 

4. Can handle unknown, uncertain, or conflicting data. 

5. Allow a programmer or user to modify segments of the 
program easily. 

6. Have a facility to explain their advice or reasoning 
process. 






7. Use if-then rules (heuristics) extensively, but not 
necessarily exclusively. [Ref. 3] 

Expert systems can be created for a computer using 
programming languages, expert system shells, or system 
development tools which fall between programming languages and 
shells. Programming languages provide the most flexibility, 
but they are more difficult to use because the system 
developer is required to design from scratch both the 
knowledge base and the inference engine to access it. Using a 
programming language is therefore more expensive and time- 
consuming. An expert system shell can be easier and quicker to 
use than programming languages or development tools. Since the 
inference engine is preprogrammied in an expert system shell, 
a systems developer's main work is to create the knowledge 
base, Microcomputer versions of expert system shells, such as 
VP Expert, are especially useful for developing prototype 
systems such as will be developed in this study. Expert system 
shells are easily affordable and readily available on the open 
market. Expert systems developed using a shell are also easier 
to expand, update and maintain [Ref. 3] . In the case of VP 
Expert, the expert system shell selected for this study, 
technical assistance is available from the manufacturer over 
the phone [Ref. 4]. A system for shipboard maintenance could 
easily be developed and maintained by personnel with limited 
computer background or expertise. 
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C. DATABASE MANAGEMENT SYSTEMS 


A database is a self-describing collection of integrated 
records. It is self-describing in that it contains, in 
addition to application data, a description of its own 
structure called a data dictionary. In.a database system, all 
application data is stored in the database. [Ref. 5] 

A database is more than a collection of files. It includes 
the files, a data dictionary, and a description of the 
relationships among the records in the files. These 

relationships are stored and recalled during database 
processing and are represented by additional system data known 
as overhead data. Overhead data includes linked lists, 
indexes, and similar data. It is in this manner that a 
database can be a collection of integrated records. [Ref. 5] 
The advantages of using a computerized database system in 
the shipboard environment are obvious when considering the 
current filing systems and technical libraries in use 
throughout the fleet. Databases can store large amounts of 
operational data and can be queried on an ad hoc basis, which 
makes them the ideal foundation for decision support systems. 
The data stored in a database can be readily accessed and 
processed, which allows users to get answers much faster. With 
the addition of a database management system (DBMS) the 
utility of the database is even greater. 

The DBMS is a program (or group of programs) that allows 
stored data to be integrated, reduces data duplication, 
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ensures data integrity, eliminates program dependency on file 
formats, and allows even complicated objects to be easily 
understood, represented, and retrieved. In short, a DBMS is 
the program which processes the database. [Ref. 5] 

A database system consists of five major components; 
hardware, DBMS software and application programs, the database 
itself, procedures, and people. Database systems are often 
classified by the number of users and the number of 
applications they support. [Ref. 5] 

In a single-user database system, only one user at a time 
processes the database. In a multi-user database system, the 
database is processed by many users concurrently. Multi-user 
systems require more hardware and special precautions to 
prevent two users using the system concurrently from 
interfering with each other [Ref. 5] . Database systems can 
also support one or many applications. An application is 
simply a system that processes a portion of the database in 
order to meet the information need cf a distinct functional 
area of an organization [Ref. 6]. 

For this study, a single user, multi-application database 
system will support the requirements of an engineering 
maintenance database system. There are many low cost, readily 
available commercial products to fill this requirement, and a 
microcomputer, as commonly found on most ships, will provide 
the adequate hardware. 
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D. EXPERT DATABASE SYSTEMS 


While a simple computer-based database system would 
greatly assist in providing the information needs of a ship, 
in particular in the area of engineering maintenance, such a 
system joined or coupled to an expert system presents an even 
greater range of possibilities. What makes the bridge between 
database management and an expert system possible is the fact 
that databases and expert systems' knowledge bases are both 
first and foremost information-bearing systems. Although often 
considered technically distinct and separate, their deeper, 
more fundamental similarities suggest a natural union. 

[Ref. 7] 

When moving up from a simple database to an expert 
database one should view the database as an extension of the 
knowledge base. The advantage of coupling an expert system to 
a database is that a large amount of information can be 
organized and accessed separately while the knowledge base 
remains intact. Additions, modifications, and deletions can be 
easily performed through a menu-driven format of the database 
management system without affecting the integrity or logic of 
the expert system. While most database systems are easily 
understood and learned, changes to the expert system's 
knowledge base require much more training, and the user must 
have an intimate knowledge of the logic involved. It is far 
more efficient to store large amounts of varying information 
in a database, and design the knowledge base to contain a 






single set of invariant rules. Therefore, when a database is 
used in this fashion, it becomes an information base, and can 
be considered as a part of the overall knowledge base. To 
distinguish the rules of the original knowledge base from the 
information base, they are referred to as the rule base 
[Ref. 4]. Figure 1 provides an illustration of the concept of 
the expert database system. 



Figure 1., The Expert Database System. 
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A simple expert database system consisting of a 
coiTunercially available expert system shell and a compatible 
database management system can provide an ideal system for 
assisting in the troubleshooting of shipboard engineering 
equipment. The trouble- shooting guide can be extracted from 
the technical manual to form the basis for the knowledge of 
the rule base. The logic of most troubleshooting guides lends 
itself well to the rapid translation into a series of if-then 
rules. Questions to the user will be answered, compared to the 
rule base, and a cause and solution to the problem given. A 
separate database can then be accessed by the expert system to 
provide the detailed procedures required to correct the 
problem. Since these procedures are the portions of the 
technical manual that are most likely to be changed by 
periodic technical updates from NAVSEA, their retention in a 
database facilitates ease of access and modification if 
required, without influencing the basic logic of the rule 
base. 

VP-EXPERT has been selected as the expert system shell for 
this study. It has a relatively low cost, is widely available 
and used, is easily installed on microcomputers, has good 
technical support, and has facilities for coupling with 
database files. 

DBASE IV will be used for the database management system. 
It is also readily available at a low cost, easily installed, 
has good technical support, and is compatible with VP-EXPERT. 






Together these two systems will be joined to form a prototype 
Engineering Maintenance Expert Database System. 
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III. ANALYSIS AND DESIGN OF THE EXPERT SYSTEM COMPONENT 


A. THE OVERALL SITUATION STUDIED: THE EXPERT'S DOMAIN 

1. Decision Selection 

The general area under study is the corrective 
maintenance or "troubleshooting” of a piece of machinery that 
is not operating according to prescribed specifications. For 
this study the particular machinery involved pertains to main 
propulsion or auxiliary shipboard equipment. These systems 
are largely electro-mechanical in nature with associated 
electrical and electronic control and monitoring systems. 

Troubleshooting was selected as the subject for this 
expert system development for several reasons: 

1. Troubleshooting is a vital and mission essential 
process in U.S. Naval ships, and it is performed by only 
a few selected experts in a particular ship. This 
expertise can be variable and scarce. 

2. Troubleshooting decisions involve informed judgement 
applied in a deductive logic well-suited to expert system 
development. 

3. Troubleshooting decisions are made in a reasonable 
amount of time and are clear, structured and well-defined. 

2. The Decision Making Process 

Troubleshooting is the process of analyzing the 
symptoms of a given problem, determining the cause, and 
applying a solution to correct the problem. In this process a 
qualified technician, the expert for the purpose of this 
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study, initially surveys the problem, checks a few obvious 
possible causes, and then refers to a checklist or 
troubleshooting guide if the problem was not immediately 
corrected. Troubleshooting guides as provided by most 
equipment technical manuals are usually arranged with a 
flowchart or checklist of possible causes under each of a 
number of common problems. The expert then checks each 
possible cause on the list to determine what is causing the 
problem. [Ref. 8] 

The process of checking a possible cause requires its 
own expertise as the information given in the guide is usually 
only a question as to whether or not a given condition exists. 
The technician must possess a certain expertise to make many 
of these determinations. For example, a troubleshooting guide 
may ask if a certain electrical switch is defective, and it is 
up to the technician to make that determination. The prototype 
developed for this study will be restricted to the expertise 
provided by the technical manual, but further iterations could 
be expanded to include the full expertise required of the 
troubleshooting technician. 

B. DOCUMENTING THE PROTOTYPE 
1. System Proposal 

The expert system portion of the Engineering 
Maintenance Expert Database System is constructed from a 
technical manual troubleshooting guide using the VP-EXPERT 


22 






expert system shell. For the purpose of this study, a 
prototype system was developed to troubleshoot the NAXI 100-2 
Low Pressure Air Compressor. With minimal training of a 
designated technician, similar systems could be developed and 
maintained using the technical manuals of each piece of 
engineering equipment found on a particular class of ship. 
Most technical manuals possess a troubleshooting guide which 
is logically laid out in such a fashion as to allow the rapid 
translation into a set of if-then rules of the expert system 
shell. At the low initial purchase cost of the system shell, 
virtually an unlimited number of equipments could be 
supported. Such a system would free shipboard technicians from 
reliance on numerous unwieldy paper copies of technical 
manuals while presenting a clear and concise approach to 
troubleshooting each piece of equipment. 

While users of the system could be any technician 
qualified to work on the particular piece of equipment for 
which he is troubleshooting, system development and 
maintenance should be restricted to one or two trained 
individuals to maintain the knowledge base integrity. 

2, Prototype System Description 

a. System Overview and Objective 

The prototype system will ask the user a number of 
questions about the operating conditions of the equipment to 
determine the symptoms and possible causes of a given problem. 
When a problem has been isolated, the user will be presented 




with a solution to the problem. The solution is based upon the 
backward chaining inferencing through the rule base to arrive 
at a value. 

Jb. Reconmendations to be Made by the System 

For prototyping purposes, the system is limited to 
the problems, causes and solutions given in the 
troubleshooting guide of the technical manual [Ref. 8] . A 
given problem will have several possible causes. Questions to 
the user will be used to isolate a cause and present a simple 
solution. When required, more detailed solution procedures 
will be referenced by the paragraph in the technical manual, 
and the actual procedure steps will be called and displayed 
from an accompanying database. 

3. Prototype Knowledge Base Design 

The nature of the troubleshooting problem dictates 
that there can be many possible causes to many problems, and 
in turn many possible solutions. Therefore, the knowledge does 
not lend itself well to segmentation or a standard dependency 
diagram. 

Appendix A, Figures A1 and A2 depict a graphic 
representation of the decision tree used to form the rule 
base. The first question to the user determines if the 
equipment will start when turned on. A negative response forms 
the first premise for rules 0 to 11, which all lead to causes 
why the compressor may not start and provide a solution to the 
problem. An affirmative response to the start question leads 
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the user to the remaining rules dealing with a compressor that 
starts and then shuts down. This group is further broken down 
into three groups for how long the compressor runs before 
shutting down. 

Rules 12 to 15 deal with a compressor that shuts down 
after three to five seconds, and rules 16 to 18 are for a 
compressor that shuts down within two minutes. The remaining 
rules are for a compressor that runs longer than two minutes 
before shutting down, with the exception of rules 23 to 27 
which deal specifically with high water in the separator 
holding tank, rules 49 to 54 deal with high temperature, rules 
61 to 68 which deal with low water, and rules 69 to 72 which 
deal with high liquid level in the condensate sump. Each of 
these groups are invoked separately whenever these particular 
causes have been identified because they can be causes of more 
than one type of shutdown. For example, a high water condition 
could cause the compressor to shut down in three to five 
seconds as per rule 13, or it could be the cause of an 
automatic shutdown after the compressor has run for longer 
than two minutes. In each of these cases, a separate WHILETRUE 
clause in the ACTIONS block of the program will be called to 
find the cause of the high water, high temperature, low water, 
or high condensate level. 

Referring back to Appendix A, once it has been 
determined that the compressor runs for longer than two 
minutes, then the rules are further grouped as follows: rules 
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19 to 22 and 28 and 29 deal with automatic shutdowns, rules 30 
to 33 are for a compressor that will not automatically stop or 
unload, rules 34 to 37 are for a compressor that will not 
automatically restart in the automatic mode, rule 38 is 
specifically for a safety valve lifting prematurely, rules 39 
to 47 are for low receiver air pressure, rules 55 to 60 deal 
with high seawater outlet temperature, and rules 73 to 81 are 
for an eibnormal noise in the compressor. 

C. PROTOTYPE IMPLEMENTATION 

Appendix B is provided as a sample consultation using the 
prototype system, which has been given the name The LPAC 
Troubleshooter. The user of the system is expected to be 
familiar with the VP-EXPERT's basic operations and options 
available through the introduction and control screens. 
Chapter 1 of the VP-EXPERT manual [Ref. 4] provides an 
adequate explanation of the basic commands needed, and the 
prototype's introductory screens also review how the user can 
make selections. 

Refer to Appendix B for the screen displays and the types 
of questions asked during an actual consultation with The LPAC 
Troubleshooter. 
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IV. ANALYSIS AND DESIGN OF THE DATABASE COMPONENT 


A. SYSTEM DEFINITION 

The database system developed for this study is titled The 
Shipboard Maintenance Database. It is intended to serve as a 
prototype for use with the expert system developed for this 
thesis, the LPAC Troubleshooter. As a prototype, this system 
has been developed to demonstrate the value of coupling a 
database to an expert system to form an expert database system 
to assist in the performance of corrective maintenance in U.S. 
Navy ships. While this particular database provides the 
necessary basic information to conduct certain corrective 
maintenance tasks, an actual shipboard system could be greatly 
expanded to include preventive maintenance, safety 
precautions, mission impact, and full supply interface for 
parts support. However, for the purpose of this study, the 
system scope has been limited to only those objects required 
to perform corrective maintenance. 

Users of this system would include sailors performing 
corrective maintenance on U.S. Navy shipboard auxiliary and 
main propulsion equipment, the division Leading Petty Officer 
responsible for maintaining and updating the system, the 
division Chief Petty Officer, and the Division Officer. The 
prototype for this study will use the NAXI 100-2 Low Pressure 
Air Compressor as the equipment example, but the system has 






been designed to include all of the engineering equipment in 
a destroyer-sized ship. 

As a stand-alone system without the expert system, users 
could access the database to obtain basic equipment and system 
characteristics, information on ecjuipment problems, symptoms, 
and the corrective procedures and parts required to correct a 
problem. All information used by the system will be 
restricted to, and taken directly from the equipment's 
technical manual. 

The purpose of such a system would be to effectively 
automate a ship's technical manual, thereby freeing the 
maintenance technician from cumbersome paper copies and 
providing a centralized access to technical information. As a 
separate system from the expert system, a database could be 
more easily updated and modified than the expert system's rule 
base. A separate database also allows greater access to the 
technical information for purposes other than troubleshooting. 

This study will use the DBASE IV database management 
system for implementation. This software is readily available, 
relatively easy to learn, and compatible with the hardware 
currently in the fleet. The prototype is considered entirely 
feasible in its current form as a shipboard database 
application. 
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B. USER'S REQUIREMENTS 

The user's requirements are designed to meet two goals: 
data requirements and functional requirements. 

1. Data Requirements 

Data requirements are the data elements stored in the 
database to support the applications. This study will follow 
an object-oriented methodology to fulfill these requirements. 

a. Data Objmcts 

An object is a named collection of properties that 
sufficiently describes an entity in the user's work 
environment. [Ref. 5] 

For this study, the objects defined included 
EQUIPMENT, SYSTEM, CORRECTIVE PROCEDURE, and PROBLEM. Appendix 
C provides the specifications and diagrams for each of these 
objects. 

b. Object Descriptions 

(1) Equipment Object. The EQUIPMENT object is 
used to describe any piece of main propulsion or auxiliary 
equipment found in a ship's engineering plant. Its properties 
include a name ( EName ) which it is commonly referred to, a 
specific model number (modelno) , the systems it is a composed 
of, its manufacturer ( manufact ), its technical manual 
( Techman ), and the number of units ( number ) found on this 
particular ship. Appendix C provides the full domain 
descriptions for each property. 
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(2) System Object. The SYSTEM object describes 
each of the systems which make up a piece of equipment and as 
such is an object property of the EQUIPMENT object. Its 
properties include a common name (SName), a brief description 
of its purpose (SDescript), the equipment it is found in, and 
any problem s that could be associated with the system. As an 
example, a piece of equipment such as the low pressure air 
compressor, consists of the following systems: electrical, 
air, dehydrator, fresh water injection, etc. The electrical 
system could have a problem such as open undervoltage relays. 
Problem is a multi-valued (MV) property, in that a given 
system can have many possible problems. 

(3) Corrective Procedure Object. The CORRECTIVE 
PROCEDURE object describes a procedure used to correct an 
equipment problem. It consists of a task name, a brief 
description ( TDescript ) of what it is supposed to do, the 
problem s it corrects, the specific steps ( TProcedure ) of the 
procedure, and any parts required to perform the procedure. 
For example, the task "Replace high level drain switch" is 
performed to correct the problem of "high water in the 
separator holding tank". 

(4) Problem Object. The PROBLEM object describes 
a problem that a system of a piece of equipment may 
experience. Its properties include a common name ( PName ). the 
symptom s, the cause of the problem, the corrective procedure 
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( procedure ) to correct the problem, and the system that 
usually has the problem. 

2. Fijnctional Requirements 

Functional requirements consist of the applica''ions' 
update, display, and control mechanisms used on the data 
objects to satisfy the user's information needs. They are best 
illustrated with data flow diagrams as per Figures C2 to C6 in 
Appendix C. 

An application is a collection of menus, reports, forms, 
and programs that addresses the needs of a user group. 

[Ref. 5] 

For this study the database system has been designed 
to support two applications: The Leading Petty Officer 
application and the Troubleshooting application. Appendix C 
provides a summary of the update, display, and control 
mechanisms for each application. 

a. The Leading Petty Officer Application 

According to the dataflow diagrams in Appendix C, 
Figures C2 through C6 , the leading petty officer is 
responsible for all aspects of maintaining The Engineering 
Maintenance Database. This means that this user's application 
must be able to create, edit, and delete instances of the 
EQUIPMENT, SYSTEM, CORRECTIVE PROCEDURE, and PROBLEM objects. 
Although creations and deletions would be rare, technical 
updates from NAVSEA could require frequent editing of the 
CORRECTIVE PROCEDURE object. 
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(1) Leading Petty Officer Update Mechanisips. The 
leading petty officer (LPO) creates all objects using data 
from the technical manuals. If a piece of ec[uipment is new to 
the ship or it has not yet been entered into the database, the 
leading petty officer enters all new instances of the 
EQUIPMENT, SYSTEM, CORRECTIVE PROCEDURE, and PROBLEM objects. 
Changes to the database in the form of technical updates are 
taken from data provided by NAVSEA technical updates and 
directives. These are usually changes to corrective procedures 
or parts. Figure C8, in Appendix C, is an example of a form 
that the leading petty officer would use to enter new 
EQUIPMENT, SYSTEM, CORRECTIVE PROCEDURE, and PROBLEM objects 
or to update existing instances. 

Figure C9 is a form to delete an EQUIPMENT object. 
This would be a rare occurrence and would result in removing 
the associated SYSTEM, CORRECTIVE PROCEDURE, and PROBLEM 
objects. 

(2) Leading Petty Officer Display Mechanisms. 
This application requires only one printed report, a list of 
all equipment and their technical manuals to validate the 
assigned equipment with the technical library. 

(3) Leading Petty Officer Control Mechanisms. 
The main control required for this application is to ensure 
that only the leading petty officer or his designated chief 
petty officer (CPO) or division officer (DIVO) has access to 
add, delete or edit data. This can probably best be achieved 
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vith a required password to protect the integrity of the 
database. 

Jb. The Troubleshooting Applicetion 

The Troubleshooting application will be used by 
sailors acting as technicians performing corrective 
maintenance on main propulsion or auxiliary machinery. It can 
either be accessed directly through the installed DBASE IV 
DBMS, or via the VP-EXPERT expert system if a troubleshooting 
rule base has been established for the particular equipment. 

(1) The Troubleshooting Application Update and 
Display Mechanisms. This application has no create, edit or 
delete mechanisms. Maintenance technicians will access the 
database for tl'.e display or printing of information, but will 
not be able to alter the data in any way. Screen displays will 
be called to view the records of each object, or to provide a 
report of problems by system or symptoms. These displays will 
also contain the corrective procedure task to correct each 
problem. A report of the task and its procedures from the 
CORRECTIVE PROCEDURE object record can then be called for 
display, or printed and carried to the work space. Figure CIO 
shows sample reports of problems, and Figure Cll shows a 
display of the corrective procedure. 

(2) The Troubleshooting Application Control 
Mechanisms. Access to the troubleshooting application will be 
restricted by password to those petty officers qualified to 
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work on the equipment. Reports can be printed and distributed 
separately to other sailors for training purposes only. 

C. DESIGN 

The design blueprint for the Engineerii.g Maintenance 
Database includes the logical database design and the 
application design. The logical database design consists of 
the database schema, application subschemas, and relation 
diagrams and definitions, while the application design 
consists of the control mechanisms and the formats for forms, 
reports, and menus. 

1. Logical Database Design 

a. DmtMbmae Schema 

The schema or conceptual view is the structure of 
the entire database. It includes the structure of all data 
types to be used by each application [Ref. 5] . Table C2 
provides the schema of the Engineering Maintenance Database. 

b. Application Subschema 

The subschema is that portion of the database 
processed by a particular application. It is also known as the 
logical view or application view [Ref. 5] . Table C2 gives the 
subschema as each column for leading petty officer and 
troubleshooting. 

c. Relations 

The Engineering Maintenance Database is a 
relational database. In other words, it is built upon the 
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relational model. The relational model is a concept that data 
is organized and stored in two dimensional tables called 
relations. Relations can be considered files, and each row in 
the relation as a record. The concept of a record as a 
collection of data items is similar to a relation being 
considered a collection of attributes. In a relation, rows are 
called tuples and columns are called attributes. [Ref. 5] 

In designing the database, the previously 
discussed objects will be used to form relations. By a process 
known as normalization, the relations will be formed by 
transforming the object properties into attributes. A relation 
diagram will identify the relationships. A relationship is an 
association between attributes or rows. Most relationships can 
be better understood when broken down to binary relationships. 
A binary relationship is a relationship involving only two 
record types. A binary relationship can be one to one, many to 
one, or many to many. Each of these relationships can be 
either mandatory or optional. [Ref. 5] 

(1) Object Types. To transform the objects into 
relations, the structure of each object must be analyzed. In 
this system three objects are compound objects and one is an 
association object. A compound object contains at least one 
object property, that is at least one of its properties is 
actually another object. Consequently, a compound object is 
represented by at least two relations, one for each object. An 
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association object is similar to a compound object, but it is 
used to document a relationship between two or more objects. 

Refer to the object diagrams and relation diagrams 
in Appendix C. The EQUIPMENT object contains the SYSTEM object 
(MV means there are many systems), the SYSTEM object contains 
EQUIPMENT and PROBLEM objects, and CORRECTIVE PROCEDURE 
contains the PROBLEM object. Therefore, EQUIPMENT, SYSTEM, and 
CORRECTIVE PROCEDURE are compound objects. The PROBLEM object 
contains both CORRECTIVE PROCEDURE and SYSTEM objects. Since 
it documents a relationship between the SYSTEM and CORRECTIVE 
PROCEDURE objects, it is considered an association object. 
Part V of Appendix C illustrates each of the objects 
transformed into relations and their binary relationship to 
each other. 

(2) The Relationships. Each piece of equipment 
must have many systems and each system must belong to only one 
piece of equipment; therefore, the relationship is a mandatory 
one to many between the EQUIPMENT and SYSTEM relations. Each 
system can have many problems and each corrective procedure 
could correct one or many problems. Each problem must affect 
a system, and must have a corrective procedure. Therefore, the 
relational representation of PROBLEM clearly shows it to be an 
association object with mandatory many to one relationship to 
both SYSTEM and CORRECTIVE PROCEDURE. 
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(3) The Keys. The relations and relationships of 
this system form a simple network. A simple network is a 
collection of records and one-to-many relationships among the 
records where one record may have more than one parent [Ref. 
5]. In this system, PROBLEM has parents SYSTEM and CORRECTIVE 
PROCEDURE. The keys of each relation are used to form the 
relationships of a network. A key is a group of one or more 
attributes that uniquely identifies a row. Every relation has 
at least one key [Ref. 5] . For the EQUIPMENT relation, the 
equipment's name, the attribute EName, is the key of the 
relation (as indicated by underlining in the diagram). The 
one-to-many relationship is effectively formed by placing the 
key of the parent in the child (the many side), and is then 
known as a foreign key within the child. Therefore, the key of 
EQUIPMENT, EName is placed within SYSTEM to form a mandatory 
one to many relationship. The key of SYSTEM, SName, and 
CORRECTIVE PROCEDURE, Task, are placed in the child PROBLEM as 
foreign key attributes. Table Cl shows each of the attributes 
fcL each relation and their definitions, including foreign 
’leys. 

2 Application Design 

As previously discussed in the requirements portion, 
the Engineering Maintenance Database System has two 
applications: the Leading Petty Officer and Troubleshooting. 
Each api^lira-ion subschema was summarized in Table C2, and the 
scope of each application was thoroughly discussed under the 
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database requirements. This section will cover the application 
control mechanisms, and the design of the menus required. 

a. Control Mechanisms 

Control mechanisms can be either menu-driven, 
command-driven, or a combination of the two. The applications 
in this system will be menu-driven for the following reasons; 

1. Although slightly slower, menus are largely self- 
explanatory and easier to use than commands. 

2. Time for training is at a premium aboard ship, and menus 
require less training. 

3. There is no need for exceptionally fast data input or 
retrieval. 

Jb. Menu Options 

The first menu is the Main Menu, and it will 
direct the user to the application desired. Figure C12 is an 
example of the main menu options. The next level will present 
the user with a list of options for the application chosen. 
For the Leading Petty Officer application, the next menu is 
shown in Figure C13. The second level menu will provide a list 
of actions that can be performed on the object data selected 
from the first level menu. Figure C14 is an example of the 
second level menu for the Leading Petty Officer application 
when equipment is selected. A similar menu would appear for 
each of the other objects if selected. A selection from this 
menu would lead to the required form or report to perform the 
action selected. The term "browse" refers to viewing the 
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records without modifying them, and the "print equipment list" 
refers to the equipment technical manual list previously 
discussed in the requirements section. 


The menus for the Troubleshooting application are 
similar except the options for the user are restricted to 
browse and print. 

The second level menu offers the user access to 
the CORRECTIVE PROCEDURE and PROBLEM objects only. Figure C15 
is an example of the Troubleshooting first level menu. The 
second level menu offers the actions available in this 
application. For corrective procedure data, the second level 
menu would appear as Figure Cl6. 

For problem data, the user would be presented with 
more options since there are additional reports available for 
this data. Figure C17 is an example of the second level menu 
for problem data. Selection of display or print problems 
report would lead to a third level menu for the user to select 
the problems by system or problems by symptom report as 
previously discussed in requirements. Figure C18 is the third 
level menu for these options. Selection from this menu, as 
with previous menus presented, will require additional forms 
so that the user can indicate the desired record data, such as 
the problems for what system or symptom. 
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D. IMPLEMENTATION 


The Engineering Maintenance Database was implemented using 
the commercially available DBASE IV software package. DBASE IV 
was selected because of the author's own familiarity with the 
system and its widespread use and availability. 

1. Creating the Database Files 

A separate directory was first established within 
DBASE IV for inclusion of the Engineering Maintenance 
Database. From the DBASE IV control center screen, a separate 
catalog was created titled ENGMAINT.CAT to hold all files, 
forms, reports and the two applications. 

Database files were created for each of the objects 
defined in the requirements phase, with their names shortened 
within the required eight characters of a DOS filename. The 
files included: EQUIP (for equipment), SYSTEM, CORRECT (for 
corrective procedure), and PROBLEM. The file structures 
followed the domain and relation definitions of the 
requirements phase, with the exception of the CORRECTIVE 
PROCEDURE property TProcedure. This property was defined to 
hold a series of procedures within a memo field that should be 
followed to complete a corrective procedure task. The original 
database file CORRECT was structured in accordance with the 
object CORRECTIVE PROCEDURE domain definition for TProcedure. 
Sample records were placed in the file and worked well within 
the confines of the DBASE IV environment. Problems arose when 
attempting to use the CORRECT.DBF file with VP-EXPERT and the 
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LPAC TROUBLESHOOTER program. Although VP-EXPERT can call most 
.dbf files, it would not call files with a memo field. 
Therefore, the TProcedure field of the CORRECT file had to be 
limited to the maximum 254 characters of a normal field. This 
created a severe limitation in space available for the 
corrective procedure steps. 

2. Creating the Forms and Reports 

Custom forms and reports were created quickly using 
DBASE IV's form and report design screens and form generators. 
Final products closely resembled those presented in the design 
phase with a few alterations for practical purposes. 

A form was not created for deletion of files as this 
function is performed easily using the installed DBASE IV 
menus. A form format was chosen for the problem reports by 
system and symptom since the lengths of the fields made a 
columnar format impractical and difficult to read. 

The forms for entering and updating file records use 
fields with 50 character window widths. If the field contains 
data of greater than 50 characters, then the data can be 
entered or read by using the cursor arrows to scroll the data 
through the window. Directions to this effect are in the field 
labels and as memos at the bottom of the screen when the field 
is in use. 

3. Creating the implications 

The Leading Petty Officer and Troubleshooting 
applications were created using the DBASE IV application 
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generator. The menus created differed only slightly from those 
presented in the design phase, and in the sample screens given 
in Appendix C, part VI. Since both applications are within the 
ENGMAINT catalog, there was no need for a main menu holding 
both applications. Either application can be selected from the 
DBASE IV control center within the ENGMAINT catalog. Passwords 
were not used within the scope of this implementation, but 
each of the applications could easily be protected using DBASE 
IV's file protection system. 

a. The Leading Petty Officer Application 

This application was created under the name LPO. 
It's main menu is in a horizontal bar format with each 
selection leading to a pop-up menu. A separate exit option was 
included to allow exiting back to the DBASE IV control center 
or to DOS. The pop-up menus closely follow the second level 
menus presented in the design phase, and their actions use the 
custom forms and reports already created. The delete action 
uses the same form as the add and modify actions, but the user 
is unable to add or modify from this selection. Deletion is 
performed using the DBASE IV Menus (FIO), selecting Records 
and Mark Record for Deletion or Blank Record. The browse 
action will display all records in DBASE IV's columnar browse 
format. 

Under the Equipment Data selection, the fifth 
selection on the second level menu will produce the equipment 
technical manual report presented in the design phase. The 
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system, corrective procedures and problem data selection are 
all the same as the equipment data, except there are no 
reports. 

b. The Troubleshooting Application 

This application also uses a horizontal bar menu 
for the main menu, and menu selections are the same as 
presented in the design phase. The same exit menu is also used 
in this application. Under problem data, the second level menu 
offers a browse selection which allows viewing with no add, 
modify or delete capability. The Print a Specific Problem 
selection calls a command file which asks the user for the 
specific problem to print in the report format PROBREP. The 
Problems Reports selection activates a third level menu which 
offers a problem report by system or symptom. Each of these 
selections calls a separate command file which asks the user 
for the system or the symptom desired. When the system or 
symptom is provided, the reports are printed in the SYSPROBS 
or SYMPROBS formats. 

The corrective procedures selection from the main 
menu activates a second level menu which allows the user to 
either browse the corrective procedure records, or print a 
desired corrective procedure. The latter selection calls a 
separate command file which asks the user which corrective 
procedure should be printed. 
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4. Data Input 


The actual records created within the database files 
were the minimum required to illustrate the database system's 
capabilities and potential for shipboard use. Data on the low 
pressure air compressor was input as the only piece of 
equipment, but the system could contain data on all shipboard 
equipment. All corrective procedures that could be called by 
the expert system were included, but not all possible 
corrective procedures were included. The EQUIPMENT, SYSTEM, 
and PROBLEM files contain only one record each for sample 
purposes. 

A complete working system would require records for 
each piece of equipment, each system within that equipment, 
all possible problems, and each corrective procedure. 


44 




V. CONCLUSIONS AND LESSONS LEARNED 


A. FIRST PROTOTYPE DEMONSTRATION 

The first prototype consisted of the first version of the 
expert system without an associated database. Additionally, 
the rules for several of the branches of the decision tree had 
not been fully implemented; specifically the high water, low 
water, and high condensate branches. It was intended to simply 
demonstrate the concept of using an expert system for 
shipboard maintenance, and to allow users to provide first 
impressions toward its potential for useful application. 

The initial prototype was demonstrated for review by SIMA, 
San Diego. The demonstration was conducted on an actual shop 
computer in the Compressor Maintenance Shop, and the prototype 
was run by sailors who perform compressor maintenance aboard 
ships stationed in San Diego. In addition, each of the 
technicians who used the system had recently served on a U.S. 
Naval ship, and were intimately familiar with the environment 
and current troubleshooting practices in the fleet. User 
experience levels ranged from the Repair Officer (05) and 
Assistant Repair Officer (04) , both of whom are degreed 
engineers and classified as engineering duty officers, to the 
shop chief petty officer (E7) and two shop technicians, a 
second class and third class petty officers (E5 and E4). 






All users quickly picked up how the system worked in a 
matter of minutes and agreed that a system of this type would 
be very useful aboard ship. All agreed that such a system 
would avoid many of the problems previously cited, and fleet 
sailors could be trained to utilize and maintain the system. 
A copy of the system was left for an extended review of 30 
days, after which observations were recorded. Suggested 
additions to the system revolved mostly around user interface 
issues. Some of the suggestions given were as follows: 

1. Improve the user interface with touch screens, light 
pens, or mouse support. 

2. Include graphics to facilitate user interface, i.e. 
provide a picture or graphic representation of the 
machinery so the user can mouse on to a part or component 
suspected and shortcut the majority of the rule base 
(reduces consultation time). 

3. Link the system with the Supply Department's parts 
database, i.e. if a solution requires a part replacement 
then the user can check its inventory status and fill out 
a requisition through the system. 

4. Increase the references to the technical manual, and 
provide all corrective procedures as called for in the 
recommended solutions. 

Each of these suggestions could lead to a greatly enhanced 
system, especially in terms of ease of user interface. 
However, they were each determined to be beyond the scope of 
this study, with the exception of portions of suggestion 4. 

Suggestion 1 would entail the use of hardware not yet 
available in the fleet. Although VP-EXPERT provides mouse 
support, it is only available in the graphics mode of 
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operation. VP-EXPERT does provide for the incorporation of 
graphics within a consultation as suggested by 2, and follow- 
on studies could possibly explore the incorporation of this 
feature. 

Suggestion 3 would best be addressed through the 
manipulation and interface isi^ues of current shipboard 
databases for parts support. While this study explores the 
possibility of linking an expert system with a database, as 
broad a system as suggested is beyond the scope of this 
prototype. 

Suggestion 4 was partly incorporated in successive 
iterations of the prototype. References to the technical 
manual, when applicable, were placed within appropriate 
solutions in the program. The initial prototype did not couple 
with a database, but a skeletal sample database has been 
developed and linked to the system to show the added 
capabilities and increased effectiveness possible with an 
expert database system. The development and implementation of 
the complete database required for a working system was also 
beyond the scope of this study. 

B. THE SECOND PROTOTYPE 

The second prototype of the expert system included all 
possible branches of the decision tree. All references to the 
technical manual were included, and additional clauses were 
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added to link the system to the Engineering Maintenance 
Database. 

Within the ACTIONS block, a MENU clause was added to 
assign the CORRECT.dbf file's TASK field as the choices for 
the Procedure variable. A separate ASK statement for Procedure 
asks the user which procedure is desired, and presents a list 
of the records within the CORRECT file, by task name, for the 
user to choose from. The FIND Procedure clause is used to 
trigger the ASK Procedure statement after all solutions that 
require a corrective procedure. When the user selects the 
desired task from the list, a WHILETRUE clause in the ACTIONS 
block calls the record selected from the CORRECT file and 
triggers a FIND Message clause. This clause causes the first 
rule (RULE 00) to fire and display the TProcedure field of the 
record for the task selected. 

The end result was a prototype for a simple expert 
database system. The second prototype was demonstrated to the 
same group of users from SIMA, San Diego. All users found the 
system easy to master, and quickly picked up the additional 
capability to call and view corrective procedures. The added 
potential offered by such a system was quickly recognized, and 
all agreed that such a system would be of value for performing 
shipboard maintenance. Their review and evaluation of the 
system resulted in the following additional suggestions: 

1. The window for the display of the corrective procedure 

needs to be larger to allow a more detailed and clear 
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listing of the procedure's steps as contained within the 
technical manual. Use less abbreviations within the text 
of the steps. 

2. Parts should be included with the corrective 
procedure. Their description should include their stock 
number, and the technical drawing number they are found 
within. 

3. The ability to call and view drawings would be useful 
in the troubleshooting process. 

4. Some of the task names presented in the list of 
procedures were unclear as to their purpose or function. 

5. It would be useful to be able to manipulate the 
database management system from VP-EXPERT to conduct 
queries. 

6. Incorporate the database within the new CD-ROM 
technology. 


As with the first prototype, each of the suggestions made 
by the users could lead to a greatly enhanced and more 
powerful system. Suggestion 1 deals with the field constraint 
of DBASE IV of 254 characters because of the inability of VP- 
EXPERT to call files with memo fields. Possibly another expert 
system shell could perform this function, but the current 
version of VP-EXPERT is limited in this respect. A possible 
solution would be to continue the procedure's steps in 
additional 254 character fields which could also be called by 
the expert system. This would allow the procedures to be 
displayed in their entirety as per the technical manual. 

Suggestion 2 could be implemented by including parts' 
stock numbers and drawing numbers in the Parts field of the 
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CORRECT file. The expert system could then call and display 
this field in addition to TProcedure. 

Suggestion 3 is not practical using VP-EXPERT. While the 
system can incorporate graphic images and diagrams created in 
GMODE, its drawing function is primitive and only the simplest 
system drawing could be made. The detail required for serious 
troubleshooting is found in the technical manual or ship's 
drawings. VP-EXPERT is unable to call and display a graphic 
file such as .pcx. A simple line diagram displayed when a rule 
fires might provide some illustrative value for the user. 

Suggestion 4 is a limitation of VP-EXPERT. Field names 
displayed as menu choices are truncated to 20 characters. 
Therefore, care must be taken to ensure a field that will be 
provided as a menu choice is as descriptive as possible within 
this constraint. 

Suggestion 5 would lead to a truly powerful expert 
database system. VP-EXPERT is unable to invoke the database 
management system, and can only call a file as specified in 
the program. Data can be read in and out of the file, but all 
of the queries, menus, and separate applications available in 
a system such as DBASE IV cannot be accessed. 

Suggestion 6 would be entirely feasible once the new CD- 
ROM technology and hardware is introduced to fleet units. CD- 
ROM offers a huge memory capacity in very little space, and 
opens many possibilities for the storage of technical 
libraries. Consideration would have to be given to the file 
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formats used, and their compatibility with an appropriate 
expert system shell such as VP-EXPERT. An expert database 
system using CD-ROM technology could bring the "paperless 
ship" concept to fruition. 

The final opinion of the users who reviewed the second 
prototype was that there are definitely many useful 
possibilities for an expert database system in performing 
shipboard corrective maintenance. While the prototype is far 
from complete as a working system, it served its purpose by 
illustrating the potential value of automating the knowledge 
found in the technical manual and human experts. 

C. LESSONS LEARNED 

The study proved to be a success in demonstrating the 
feasibility and potential of using expert database technology 
to perform shipboard troubleshooting. Using VP-EXPERT and 
DBASE IV in a prototyping approach provided some valuable 
lessons. 

1. Using VP-EXPERT 

VP-EXPERT proved to be extremely simple to use, yet 
very powerful in its expert system capabilities. It was easily 
learned using its tutorial, and the manual was relatively 
clear and straight-forward. However, some important points 
were left out of the main text, and only included in the 
keyword reference. The examples provided were excellent and 
provided some useful additions to the program. 
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VP-EXPERT's inability to call database files with memo 
fields proved to be a major source of frustration when 
attempting to couple the expert system and database. This was 
not covered at all in the manual, and only resolved with a 
call for technical assistance from the vendor. It also proved 
to be a major limitation to the expert system and the database 
system design. It could have been resolved by including the 
desired text in the knowledge base, or by calling a separate 
text file containing the procedure. However, this would have 
defeated a large part of the purpose of the study to show the 
value of coupling to a database. Inclusion in the knowledge 
base or text files would make the input and update of these 
procedures a slow and tedious process, and simply not 
practical for shipboard use. The expert system program should 
stand alone and require few changes in the future. Technical 
procedures are subject to frequent updates, and if included in 
the knowledge base would require frequent tinkering with the 
program. A database management system is a more appropriate 
tool for data that requires frequent updating. 

2. Using DBASE IV 

DBASE IV proved to be a useful and easily learned 
system for implementing the Engineering Database Management 
System. The form, report, and menu generators allowed rapid 
custom design, and the applications generator saved a great 
deal of programming time. The design screens and manual were 
straight-forward and clear. Reference 6 proved extremely 


52 





useful also, and provided excellent examples for application 
development. 

The only problems arose on several occasions when the 
system did some inexplicable actions such as switching from 
the catalog in use and failing to save several newly input 
records. Each of these occurred on several different sessions 
and can probably be attributed to "bugs" noted in the earlier 
versions of DBASE IV. Otherwise, the system was found to be 
ideal for implementing the simple applications used in this 
study. 

3. Prototyping 

Sponsorship of this study by SIMA, San Diego proved 
invaluable in the prototyping process. Because of frequent 
underway periods, it was not possible to use an actual ship 
for demonstrating the prototypes. However, since SIMA's 
primary mission is to assist ships with maintenance and 
repairs, their personnel were intimately familiar with all 
aspects of the equipment maintenance and operation, as well as 
the common practices found in the fleet. All of the sailors in 
the compressor shop had recently completed shipboard tours, 
and now work exclusively on ships homeported in San Diego. 
They proved to be an invaluable source of knowledge and 
insight into what would be useful in the shipboard 
environment. The entire command was exceptionally computer- 
literate at all levels, even the compressor shop had its own 
micro-computer tied into a local area network . The lowest 
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level technicians were conversant with micro-computer usage, 
and had definite ideas on what they liked and disliked. 

Since a large measure of the feasibility and 
usefulness of this application depended on the reaction of the 
fleet sailor as its primary user, the prototyping approach was 
the only appropriate method of development. The approach lends 
itself well to expert systems development as a whole, 
regardless of the application. The result was a system that 
illustrated to the users the unique possibilities of using 
expert systems in the shipboard environment. 

D. SUMMARY 

The study proved to be a success in answering the primary 
question of whether an expert database system is a feasible 
tool for the performance of shipboard maintenance in U.S. Navy 
ships. The prototype illustrated the potential utility of such 
a system and was favorably received by fleet sailors. 
Limitations were found in the size of the field that VP-EXPERT 
could call, which may limit the potential of the current 
version of this particular shell for this application. 
However, the inclusion of technical documentation within a 
working database, and the coupling of this database to an 
expert system, showed great potential utility, regardless of 
the particul?’- tools used. 
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APPENDIX A 


THE EXPERT SYSTEM DECISION TREE 
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Figure A1 The Lpac Troubleshooter Decision Tree (part 1) 


55 











R'36 HIGH TEtlP 


SW OUTLET TE^^F 

-|R 55 SW CIRC BLOCK 

tl Y R 56 SW STRAINER 

R57 AIROP SW VLV 

R58 MRBOUUD 

R 59 INLET TEMP {YI 

R60 INLET TEMF (H) OVERHEATED FA RT 


R 73 INSURE AJR 
R 7^ spy BAD 
R7 5 MOTOR ROTATION 
R7 6 DRIVE MOTOR 
R7 7 COUPL I NG DEFECTIVE 
R7 0 D EH YDR ATOR 
R 7 9 BACKLA Sil 
liS 0 TIMING ItlCO RRECT (T ) 

RSi TIMIIIG IUcBrRJSCT (uT - WORJtl FAR T 

II T Oil WATER 

-,n2 3 H L DS D EFECTIVE 

R2 'l AUTO R E FIL L O TEll 
B25 DRAIU BLO CEE U 
iJ2 6 AUTO U RAl!1 V ALVE BAD '(Y 
' 1( 2/ AUTO DllAIti V AL~ VE BAD (tl ) LEAK lU S W SYS 'lE11 

IIKUl TEIir 

TALK 

-p _WAIER_EBLSS 

R5 0 WATE R TEtlE' [ YI 

R51 HATER TEtlT Cu) OVEIU I EATED TART 

B52 _TEtjr_GAyGE 
B53lDEIlXDiyyT0R__lY)’_ 

R 5^ DEHYDRATOR (U)' AJR DEHYDRATO R 

LOW WATER COHO HIGH 

- RGl^rW_SUEELT ——]R6 9 H LDS SUMP DAD 

^ i^G 2 LOW L EVEL lUII EILL Y R7 0 DITA IN BLOCKED 

R63 INU S YS LEAR R71 AUT O DlL AIt-I VALVE BAD 

R64 MAITUA L DI LAIN O FEU R72 A U TO DIUVI N VALVE D/O) (tl) 

R65 A UTO D RAI U VALVE DAD " DEP LXT1VE WIRIUG 

RGG AU'J O R EFILL_BAD 

B6/ SEA L T AILED (yT~ 

RCX s e aL tailed (in mass iv e leak 



ADMOPJ1AL tIOISE 
U Y 

R0 2 

UO E'ROBLEfI 



The Lpac Troubleshooter Decision Tree (part 2 ) . 
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APPENDIX B 


I. AN LPAC TROUBLESHOOTER CONSULTATION 

A. OVERVIEW 

This appendix is an example of a consultation using The 
LPAC Troubleshooter. The figures that follow are similar to 
the actual screen displays of a consultation as run on an IBM 
AT compatible personal computer. In this appendix, the choices 
which would normally be highlighted on the monitor screen have 
been shown in bold and underlined type. 

The user must first access the VP-EXPERT program from DOS, 
and then consult the LPAC.kbs file. In an expanded shipboard 
system, there could be a separate file for each piece of 
equipment, each with its own KBS extension. For the purposes 
of this study, there is only one file available. Once the 
selected file is loaded, the user is guided through the 
introductory screens and then begins the consultation. The 
example provided in this appendix is a consultation for a 
compressor that starts, but shuts down automatically due to a 
high water level cased by a faulty high level drain switch. 
The reader may also find it helpful to refer back to the 
decision tree provided in Appendix A to trace the logic 
involved in each question of the consultation. 
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B. THE CONSULTATION 


Figure Bl is VP-EXPERT's opening screen when executed from 
DOS with the executable command VPX. To begin the consultation 
the user can select 4Consult which is highlighted, by pressing 
either 4 or Enter. A list of filenames held will be displayed 
(this list can also be called by pressing 6Filename from the 
opening screen) as in Figure B2. Each application written in 
VP-EXPERT is categorized as a "knowledge base" and given the 
extension KBS. If applications were written for other 
equipment, they would be seen here if they reside in the main 
program. If applications are stored elsewhere, they can be 
called by selecting 7Path, and specifying the drive and 
directory. For The LPAC Troubleshooter application, the user 
should select LPAC.KBS. 

Figure B3 shows the intermediate screen as the file is 
being loaded, and Figure B4 shows the blank control screen. At 
this point the user selects 2Go, which is highlighted, by 
pressing 2 or Enter. Figure B5 is the welcoming screen, and 
Figure B6 introduces the user to the system and gives basic 
instructions on how to select answers. 

Figure B7 is the screen for the first question which the 
user answers Yes to show that the compressor starts. Figure B8 
shows the next question to which the user responds Longer to 
show the compressor runs longer than two minutes. In Figure 
B9, the user responds Yes to show that an automatic shut down 
has occurred. By referring to Appendix A, it can be seen that 
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this response leads into the Autoshutdown branch of the 
decision tree. 

Figure BIO shows the first question of the Autoshutdown 
branch, and the user has indicated No for the high temperature 
question. In Figure Bll, the user again responds No to the 
high dew point question, and in Figure B12 high water in the 
separator holding tank has been identified as a symptom of the 
problem. Referring back to Appendix A at this point, it can be 
seen that this response leads to a separate tree for high 
water. In the program, this is achieved by the use of a 
separate WHILETRUE clause in the ACTIONS block. When Water 
Level=High, then this clause will fire a separate FIND High 
Water Solution. 

Figure B13 instructs the user to continue the 
troubleshooting process to find the cause of the high water. 
Figure B14 is the first question of the high water tree, and 
the user responds Yes to indicate that the high level drain 
switch is defective. Figure B15 is the solution to the problem 
instructing the user to replace the switch. 

In this particular example the solution may appear overly 
obvious, but the value of these systems are often in the 
preceding questions which triggered the user to check the 
switch. Once the cause of the problem has been identified, the 
solution is often obvious. This particular example took less 
than one minute to run, and the longest possible example has 
never taken more than two minutes. In actual troubleshooting 
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cases aboard ship, it is expected that consultations could 
take considerably longer since the machinery itself must be 
checked to make the determinations required to answer the 


questions. The time required for a consultation is 
to be well within the 20 minute envelope 
appropriate for expert system applications. 


considered 

considered 
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VP-EXPERT 
Version 2.1 
Copyright (c) 1988 
By Brian Sawyer 
All Rights Reserved 

Editor Portion Copyright(c) 1984,1985,1987, Idea Ware Inc 


Published by Paperback Software International 


RULES 


FACTS 


IHelp 2lnduce 3Edit 4Consult 5Tree SFilename 7Path 8Quit 
IHelp 2Go 3Whatif 4Variable 5Rule 7Set 8Edit 9Quit 


Figure B1 VP-EXPERT's opening screen. 


VP-EXPERT 
Version 2.1 
Copyright (c) 1988 
By Brian Sawyer 
All Rights Reserved 
Editor Portion Copyright (c) 1984, 1985, 


1987, Idea Ware 


FILES 


Choose a file; 


LPAC.KBS 


IHelp 2lnduce 3Edit 4Consult 5Tree6Filename7Path SQuit 
IHelp 2Go 3Whatif 4Variable 5Rule 7Set 8Edit 9Quit 


Figure B2 VP-EXPERT's screen listing available knowledge 
bases. 
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t KBSiLPAC] 


Loading file... 


RULES 

FACTS 

IHelp 2lnduce 3Edit 4Consult STree 6Filename 7Path 8Quit 
IHelp 2Go 3Whatif 4Variable SRule 7Set 8Edit 9Quit 


Figure B3 VP-EXPERT's intermediate screen while loading 
program. 



IHelp 2Go 3Whatif 4Variable 5Rule 6Set 7Edit 8Quit 
IHelp 2HOW? 3Why? 4Slow SFast 6Quit 

Figure B4 Program loaded and ready to run, 2Go selected. 
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WELCOME TO THE LPAC TROUBLESHOOTER! 


Press any key to begin consultation 


IHelp 2Go SWhatif 4Variable SRule 6Set 7Edit 8Quit 
IHelp 2How? 3Why? 4Slow SFast 6Quit 


Figure B5 The LPAC Troubleshooter welcoming screen. 


This expert system will help you troubleshoot the 
NAXI 100-2 Low Pressure Air Compressor. You will be 
presented with a series of questions which will be 
used to find the solution to your problem. To select 
an answer, use the cursor keys to highlight your 
choice, press enter, and then the end key. 

Press any key to continue. 


IHelp 2Go 3Whatif 4Variable SRule 6Set 7Edit 8Quit 
IHelp 2How? 3Why? 4Slow SFast 6Quit 


Figure B6 The introduction and instruction screen. 
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Does the 

Yes 

compressor start when manually turned on? 

No 





Enter to select END to complete /Q to Quit ? for Unknown 


Figure B7 The first question with yes selected. 


Does the compressor start when manually turned on? 
Yes No 

How long does the compressor run before stopping? 
3-5 Secs 2 Min Longer 


Enter to select END to complete /Q to Quit ? for Unknown 


Figure B8 The second question with Longer than 2 Min 
selected. 
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Does the compressor start when manually turned on? 
Yes No 


How long does the compressor run before stopping? 
3--5 Secs 2 Min Longer 

Has compressor automatically shut down with remote 
alarm? 

Yes No 



Figure B9 The third question with Yes selected for 
autoshutdown. 


How long does the compressor run before stopping? 
3-5 Secs 2 Min Longer 

Has compressor automatically shut down with remote 
alarm? 

Yes No 

Is the compressor air discharge temperature above 
160.deg? 

Yes No 


Enter to select END to complete /Q to Quit ? for Unknown! 


Figure BIO The fourth question with No selected for high 
temp. 








Has compressor automatically shut down with remote 
alarm? 

Yes No 

Is the compressor air discharge temperature above 
160.deg? 

Yes No 

Is the dehydrator dew point temperature above 65 deg? 
Yes No 


Enter to select END to complete /Q to Quit ? for Unknown 


Figure Bll The fifth question with No selected for dew point. 


Is the compressor air discharge temperature above 
160.deg? 

Yes No 

Is the dehydrator dew point temperature above 65 deg? 
Yes No 

Check the water level in the separator holding tank. 
Is it high or low? 

High Low Normal 


Enter to select END to complete /Q to Quit ? for Unknown 


Figure B12 The sixth question with high water selected. 
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Press any key to conclude consultation 


Figure B13 Instruction to continue troubleshooting high water. 


Is the high level drain switch in the holding tank 

defective? 

Yes No 




Enter to select END to complete /Q to Quit ? for Unknown 


Figure B14 Selecting Yes for high level drain switch 
defective. 
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Service or replace high level switch. 


Press any key to conclude consultation 


Figure B15 The final screen identifying the solution. 
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APPENDIX C 


THE SHIPBOARD MAINTENANCE DATABASE 

I. OBJECT DIAGRAMS 


EName 

Modelno 

- ^ 

system! MV 


Manufact 

Techman 

Number 


EQUIPMENT 


SName 

SDescript 


EQUIPMENT 


PROBLEM 

MV 


SYSTEM 


Task 

TDescript 


PROBLEM 


MV 


Procedure 

Parts 


CORRECTIVE 

PROCEDURE 


PName 

Symptom 

Cause 


MV'^ - multivalued 


CORRECTIVE 

PROCEDURE 


SYSTEM 


PROBLEM 


Figure Cl,; Engineering Maintenance Database System object 
diagrams. 
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II. OBJECT SPECIFICATIONS 


A. OBJECT DEFINITIONS 

1. Equipment Object 

EName; Equipment names 

Modelno; Equipment model numbers 

SYSTEM/ SYSTEM object/ SUBSET [SNAME] MV 

Manufact/ Manufacturer's name 

Techman/ technical manual number 

Number/ number of units 

2. System Object 

SName/ System names 
SDescript/ System purpose 

EQUIPMENT/ EQUIPMENT object/ SUBSET [EName] 

PROBLEM/ PROBLEM object/ SUBSET [PNAME] MV 

3. Corrective Procedure Object 

Task/ Task name 

TDescript/ Action performed 

Procedure/ Corrective procedures 

PROBLEM/ PROBLEM object/ SUBSET [PName] MV 

Parts/ Equipment parts MV 

4. Problem Object 

PName/ Problem name 

Symptom/ Problem symptoms 

Cause/ Cause of problem 

SYSTEM/ SYSTEM object/ SUBSET [SName] 

CORRECTIVE PROCEDURE/ CORRECTIVE PROCEDURE object, 
SUBSET [Task] 
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B. DOMA.IN DEFINITIONS 


1. Cause 

Text 100 

What is causing the problem 

2. EName 

Text 30 

Name of a specific piece of equipment 

3. Manufact 

Text 30 

Name of the manufacturer 

4. Modelno 

Text 15 

Unique alpha-numeric combination identifying the 
equipment 

5. Number 

Numeric 2 

The number of units of an equipment found aboard ship 

6. Parts 

Text 100 

A list of parts required to perform the task. Each 
part given by technical manual figure/index number. 

7. PName 

Text 50 

The name of the problem in a piece of equipment 

8.. SDescript 

Text 250 

A brief description of the purpose and function of a 
system 

9.. . SNeune 

Text 30 

Name of a system found in a piece of equipment 

10.. Symptom 

Text 100 

A description of the symptoms of the problem 

11. Task 

Text 30 

The corrective maintenance job to be performed 
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12. TDescript 

Text 100 

A brief description of the task 

13. Techman 

Text 16 

An alphanumeric combination of the NAVSEA technical 
manual number 

14. Procedure 

Memo 

This field references a separate text file containing 
the detailed steps to perform a corrective maintenance 
task. 
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Ill, DATAFLOW DIAGRAMS 
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Figxire C 3 The EQUIPMENT Object Dataflow Diagram, 
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Figrare C 4 The SYSTEM Object Dataflow Diagram. 
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Figure C5 The Corrective Procedure Object Dataflow Diagram 
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Figure C6 The PROBLEM Object Dataflow Diagram,, 
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IV. UPDATE, DISPLAY AND CONTROL MECHANISMS 


A. LEADING PETTY OFFICER APPLICATION 

1. Update Mechanisms 

a. Add EQUIPMENT, SYSTEM, CORRECTIVE PROCEDURE, and 
PROBLEM Data 

(1) Inputs. New equipment technical manuals. 

(2) Outputs. New EQUIPMENT, SYSTEM, CORRECTIVE 
PROCEDURE, and PROBLEM object instances in 
database. 

(3) Frequency. As new equipment arrives. 

Jb. Edit EQUIPMENT, SYSTEM, CORRECTIVE PROCEDURE, and 
PROBLEM Data 

(1) Inputs. Technical updates from NAVSEA. 

(2) Outputs. Modified object instances in the 
database. 

(3) Frequency. As updates are received. 

2. Display Mechanisms 

a. Qumry on EQUIPMENT, SYSTEM, CORRECTIVE PROCEDURE, 
and PROBLEM 

(1) Output Description. Forms showing all object 
data. 

(2) Source Data. Objects/ equipment, system, 
corrective procedure, or problem names keyed in by 
user. 

(3) Processing Notes. Used by LPO, CPO, or DIVO. 

(4) Frequency. As required. 

Jb. Equipment Technical Manual List 

(1) Output Description. A report showing all 
EQUIPMENT object instances and their respective 
tec’ .lical manuals. 

(2) Source Data. EQUIPMENT object/ keyed 
request for equipment report. 

(3) Processing notes. Used to validate 
technical library. 

(4) Frequency. Quarterly. 

3. Control Mechanism - access by password. 
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B. TROUBLESHOOTING APPLICATION 


1. Update Mechanisms - none. 

2. Display Mechanisms 

a. Query on EQUIPMENT, SYSTEM, COIAECTIVE PROCEDURE, 
and PROBLEM 

(1) Output Description. Forms showing all object 
data. 

(2) Source Data. Objects; equipment, system, 
corrective procedure, or problem names keyed in by 
user. 

(3) Processing Notes. Used by LPO, CPO, or DIVO. 

(4) Frequency. As required. 

Jb. Problems by Syn^tom Report 

(1) Output Description. A report showing all 
problems for a given symptom and their corrective 
procedure tasks. 

(2) Source Data. CORRECTIVE PROCEDURE and 
PROBLEM objects; keyed request for problems by 
symptom report. 

(3) Processing Notes. Used by maintenance 
technician for troubleshooting equipment. 

(4) Frequency. As required to troubleshoot. 

c. Problems by System Report. 

(1) Output Description. A report showing all 
problems for a given system and their corrective 
procedure tasks. 

(2) Source Data. SYSTEM, CORRECTIVE PROCEDURE 
and PROBLEM objects; keyed request for problems 
by system report. 

(3) Processing Notes. Used by maintenance 

technician for troubleshooting equipment. 

(4) Frequency. As required to troubleshoot. 

d. Corrective Procedure Report 

(1) Output Description. A report showing the 
corrective procedure for a problem. 

(2) Source Data. CORRECTIVE PROCEDURE and 

PROBLEM objects; keyed request for corrective 

procedure report. 

(3) Processing Notes. Us^ a <'y maintenance 

(technician for troubleshooting equipment. 

(4) Frequency - as required to troubleshoot. 
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III. RELATIONAL DIAGRAM 



Figure C7 Engineering Maintenance Database System 


Table Cl. Relation Definitions 
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VI. FORMS, REPORTS AND MENUS 


EQUIPMENT DATA 


XXXXXXXXXXXXXXXXXXX 

XXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXX 

NAME 

MODEL NUMBER MANUFACTURER 

XXXXXXXXXXXXXXXXXXXX 

XXX 

TECHNICAL MANUAL 

NUMBER ONBOARD 

SYSTEM DATA 


XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

NAME 

DESCRIPTION 

CORRECTIVE PROCEDURE 

DATA 

XXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

TASK 

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

XXXX 

DESCRIPTION 

PROCEDURE (MEMO) 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

PARTS 


PROBLEM DATA 


XXXXXXXXXV-XXXXXXX xxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx 
NAME SYMPTOM CAUSE 


Figure C8 Leading Petty Officer Update Forms. 


Enter name of EQUIPMENT to delete: XXXXXXXXXXXXXXXXXXXXX 
This is the record for the equipment: 

XXXXXXXXXXXXXXXXXXX xxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxx 

Equipment name Model number Technical manual 

Is this the correct equipment to delete? (Y/N) 

Figure C9 Form for Deleting EQUIPMENT. 
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PROBLEMS BY SYSTEM 


SYSTEM PROBLEM CORRECTIVE PROCEDURE 

PROBLEMS BY SYMPTOM 

SYMPTOM PROBLEM CORRECTIVE PROCEDURE 

Figure CIO Troubleshooting Reports of Problems 


TASK: 

DESCRIPTION: 

PROBLEMS CORRECTED: 
PROCEDURE: 

I 

PARTS REQUIRED: 


Figure Cll Troubleshooting Corrective Procedure Report. 
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Table C2. Datedsase Schema. 


DATA \ APPLICATION 

LEADING PETTY 
OFFICER 

TROUBLESHOOTING 

EQUIPMENT 

X 


SYSTEM 

X 

X 

CORRECTIVE 

PROCEDURE 

X 

X 

PROBLEM 

X 

X 


MAIN MENU 

1. LEADING PETTY OFFICER APPLICATION 

2. TROUBLESHOOTING APPLICATION 

3. EXIT 


Figure C12 The Engineering Maintenance Database Main Menu, 




LEADING PETTY OFFICER 

1. Equipment data. 

2. System data. 

3. Corrective Procedure data, 

4. Problem data. 


Figure C13 The Leading Petty Officer First Level Menu, 
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EQUIPMENT 

1. Add new equipment. 

j 

2. Modify existing equipment. 

3. Delete equipment. 

! 

4. Browse equipment. j 

I 

5. Print equipment list. 


Figure C14 The Leading Petty Officer Second Level Menu for 
Equipment. 




TROUBLESHOOTING 

1. Problem data. 

2. Corrective Procedure data. 


Figure CIS The Troubleshooting Application First Level Menu 
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CORRECTIVE PROCEDURES 


1. Browse records. 

2. Print selected record. 


Figure C16. The Second Level Troubleshooting Menu for 
Corrective Procedures. 


PROBLEMS 

1. Browse problem records. 

2. Print selected problems. 

3. Display problems report. 

4. Print problems report. 


Figure C17 The Second Level Troubleshooting Menu for Problems. 


♦ 


f 
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DISPLAY PROBLEMS REPORT 


1. Problems by system. 

2. Problems by symptom. 


Figure C18. The Third Level Troubleshooting Menu for Display 
Problems Report. 
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